…nto development

Unclear why this should be disabled. It works as any other situation might.

Non project file solution items (.props/.json/etc files) will not have a subproject.

The Error List has 2 problems.
1) It will contain errors for projects that are not in the dependency chain of the Raspberry Project. (so the launch would fail even though the target project built successfully)
2) It is slow to be updated which can result in reporting an error that's no longer valid after the build completes.
Instead, Look at LastBuildInfo to determine if any project failed to build, and if so, redirect to the Error List window (give it focus) and notify.

Since we add publish errors to the Output Window. Adding to Error List is much more complicated.
See: https://github.com/microsoft/VSSDK-Extensibility-Samples/blob/master/ErrorList/Readme.md

Allows different behavior when errors occur.

If you dig into the VS bug report you'll see that the OS bit size can't be determined by the processor only. Whether that's a bug in Raspian or not is not for me to argue.

For the time being assume the default is "linux-arm64".  This could be inferred from the the Pi Status.Architecture property but some program flow will need adjustments. Could also put it in the ProjectSettings.

VS's Attach to Process command installs and uses the debugger in the user's context. Mimic that here. But it's never updated (Future?).

Building will not change the project output unless required by edit or dependency change.  Record the previously uploaded file info and use that to trigger another upload if needed.

Writing log information to the Debug pane is lost as soon as the debugger launches because VS clears that pane.  Create a specific pane for the extension so that the log is retained until the next command.

Use the project's required SDK and the PiStatus to determine if the needed SDK is installed. If not, then add.

Suspicion confirmed, output file isn't enough, but it appears that tracking the directory might work.

Use the Microsoft based install scripts to install the needed SDK. This removes the need for the SDK catalog updates. As is used now this will cause the most up to date .NET SDK to be installed. TODO: Call this script at least once per session so that the SDK can be updated, Or, possibly track to the Project's global.json file to make sure the required is installed.

Force the --architecture flag on the .NET SDK download/install ops.

Pass the projectsettings object into the connect retry to prevent exception on subsequent operations.  Also add arch to text for SDK install.

correct "Accessing "DTE2" should only be done on the main thread." warnings.

Remove VS NuGet references which were causing "The extension is incompatible with the targeted version of Visual Studio"
Update various other packages.

Using Private Key access results in an exception in VS2022 when MAUI workloads are installed because they force the Neon.SSH component to use the newest version (loaded by VS). Updates to Neon.SSH are beyond our control, so hack a solution:  Clone Neon.SSH in an adjacent dir to this project, reference the Neon components specifically, and force the update of SSH.NET that's required to avoid the exception. The update forces a single line change for a nullable at present. Otherwise, it's just a recompile to pick up on the introduction of an Interface.

If the PlatformTarget is ARM32/64 then assume this can be executed on a Pi.  This is sorta a stop gap because it is expected that the project sets the RuntimeIdentifier to "linux-arm64" but the property isn't included in the active config (or anywhere I could find) so use this for now.

If debugging of application startup occurs then the webserver will not have begun and a timeout exception will kill the debugging process. Catch and ignore so that debugging can continue. The browser will not be launched in this case.

Add ci cd

Use where necessary and log the Publish command line.

Add target framework

Use the Active Debug Profile property as the key to read the LaunchSe…

Previously one could only set Project Debug settings if ALL project settings produced a Linux/Pi supported output. This was confusing. Allow the dialog to come up for ANY executable/Asp/Core project. The build/Run/Debug will behave correctly if the project can't be executed on Linux/Pi.

Add a property defining the Target Arch. This allows the system to filter what can/can't run on that target. Not used right now and added to remind for future work.

 Errors in Output/Publish folder paths resulted in pointing to the wrong locations and not uploading the updated output.

More learning

Add pi5

Update the required dependencies for the lates Raspian/Raspberry Pi OS based upon MS docs:
https://learn.microsoft.com/en-us/dotnet/core/install/linux-debian?tabs=dotnet10#dependencies

Use script to test for Debian version to maintain previous functionality. As Raspberry Pi apparently has always been Debian based this should be backwards compatible.
https://stackoverflow.com/a/75195665

This code will manage the version of VS that the extension is currently being used in.
It helps determine what debugger should be installed and where it is installed on the Pi.  MS docs suggest that the version can be selected but don't really provide info on the valid values. Also, while vs2022 works, vs2026 currently does not. So just go with latest for now.

It would seem that this was defaulted to ON in earlier visual studio versions.

Fix: .NET SDK install was failing with missing dependencies

Previously this was tied to a specific problem fix branch I had. As It's likely I'll need to do more work in my fork to keep this operating for the foreseeable future, I'm moving to a "development" branch to track my work and keep it isolated from the downstream source.

Update dependencies